One of the most important features of a database is that it provides a certain degree of isolation between its data structures and software that uses them. Unfortunately, this degree of isolation is often low in the real world, especially in cases where the system architecture is not specifically designed to support future modifications to the database schema. In such cases, expensive software modifications that effectively drop the system's usability to zero may result.
The most common and simplest example of a database modification is adding an attribute to a table. Even this simple example, however, normally requires: altering the table design to add the attribute, and modifying the front-end software so that it gives users access to the new attribute (unless the attribute names are retrieved from the database and they are self-explanatory). In a more complex example, the new attribute may belong to a relationship that does not exist in the database. In this case, the modifications will involve creation of a new table and significant changes to the software to make use of the newly created table.
Although certain conventional approaches generally work fine for adding or deleting attributes of objects or existing relationships without modifying the software that uses the database, they generally do not support transparent adding of a new attribute if the table representing the relationship does not already exist in the database.